《UML系统分析与设计》复习纲要+习题答案 | 您所在的位置:网站首页 › 软件开发 A类 B类 C类 › 《UML系统分析与设计》复习纲要+习题答案 |
《UML系统分析与设计》复习纲要
第1章 面向对象技术概述第2章 统一建模语言UML概述第3章 用例图第4章 类图与对象图第5章 顺序图与协作图第6章 状态图与活动图《UML系统分析与设计》复习参考答案
答案地址(跳转不了就复制到浏览器打开):https://blog.csdn.net/bueke/article/details/105522391
第1章 面向对象技术概述
复习题 1-1. 领域模型又称为( ) A. 用例模型 B. 概念模型 C. 分析模型 D. 设计模型 1-2. ( )是面向对象方法中用来描述“对客户隐藏对象的属性和实现细节”的概念。 A. 封装 B. 继承 C. 多态 D. 抽象 1-3. 使得在多个类中能够定义同一个操作或属性名,并在每一个类中有不同的实现的一种方法是( )。 A. 继承 B. 多态 C. 约束 D. 接口 1-4. ( )是指同一操作作用于不同的对象可以有不同的解释,产生不同的执行结果。 A. 继承 B. 多态 C. 封装 D. 泛化 1-5. 已知f1和f2是同一个类的两个成员函数,但f1不能调用f2,说明( )。 A. f1和f2都是静态成员函数 B. f1是静态成员函数,f2不是静态成员函数 C. f1不是静态成员函数,f2是静态成员函数 D. f1和f2都不是静态成员函数 1-6 判断( ) :面向对象方法中对象是从客观世界中抽象出来的一个集合体。 1-7. 判断( ) :类是面向对象程序中的构造单位,也是面向对象程序语言的基本成分。 第2章 统一建模语言UML概述复习题 2-1. UML的全称是 ( ) A. Unify Modeling Language B. Unified Modeling Language C. Unified Modem Language D. Unified Making Language 2-2. 在UML中表示一般事物与特殊事物之间的关系是( )。 A. 关联关系 B. 泛化关系 C. 依赖关系 D.实现关系 2-3. 我们可以使用UML中的( )来描述图书馆与书的关系。 A. 关联关系 B. 泛化关系 C. 依赖关系 D.实现关系 2-4. UML使用( )来描述接口和实现接口的类之问的父系。 A. 关联关系 B. 泛化关系 C. 依赖关系 D.实现关系 2-5. 下列选项中不属于UML的扩展机制的是( )。 A. 约束 B. 构造型 C. 注解 D. 标记值 2-6. UML的软件以( )为中心,以系统体系结构为主线,采用循环、迭代、渐增的方式进行开发。 A. 用例 B.对象 C.类 D.程序 2-7.UML的( )模型图由类图、对象图、包图、组件图和部署图组成。 A.用例 B. 静态 C.动态 D.系统 2-8 . UML的( )模型图由活动图、顺序图、状态图和协作图组成。 A. 用例 B. 静态 C.动态 D.系统 2-9.UML的最终产物就是最后提交的可执行的软件系统和( )。 A. 用户手册 B. 类图 C. 动态图 D.相应的软件文档资料 2-10. 在UML的需求分析建模中,( )模型图必须与用户反复交流并加以确认。 A.配置 B.用例 C. 包 D. 动态 2-11. 判断( ) :构造块就是UML中的事物。 2-12. 判断( ) :UML中的行为事物通常用来描述模型的动态部分。 2-13. 判断( ) :所有的UML图都不依赖于元素符号的大小和位置。 2-14. 判断( ) :UML的用户可以随意对UML进行任意形式的扩展。 2-15. 判断( ) :UML中的约束使用大括号中的文本来表示。 第3章 用例图要求掌握内容 参与者(Actor): 是指系统以外的–需要使用系统或与系统交互的东西–包括人-设备-外部系统等。 参与者这个概念更确切的术语应该是角色(role)–参与者是他们相对系统而言(与系统交互时)所扮演的角色(而非特定的人或事物–实际上是版型化的类)。 版型:既构造型(Stereotype) – 必须从UML中已有的基本构造块上派生 - 解决特定问题(在已有的元素上增加新的语义但没有增加新的语法) - 这就是UML的扩展机制 P38。 例如:参与者是类的构造型 – 接口是类的构造型 – 子系统是包的构造型参与者之间的关系: 泛化(generalization)关系:一般事物(称为超类或父类)和该事物的较为特殊的种类之间的(分类)关系-子类继承(共享)父类的特性(特别是属性和操作)-也可以用自己特性 P36。参与者和用例之间的关联关系: 关联(association)关系:是一种结构关系–说明一个事物的实例与另一个事物的实例间的(通信)联系(P36) – 参与者和用例之间的关联关系-表明了哪个参与者与用例通信。用例的概念: (1)用例由一组用例实例(场景)组成-在商场购物“付款”的用例中-一个是使用现会成功付款的场景-一个是由于银行卡付款被拒绝造成的付款失败场景。 (2)用例从使用系统的角度描述系统–即站在系统外部察看系统功能-而不考虑系统内部对该功能的具体实现。 (3)用例的执行结果对参与者来说是有意义的–登录系统是一个有效的用例–但输入密码却不是–因为登录系统对参与者有价值–这样他可以获得身份认证和授权。 (4)用例是对系统行为的动态描述-属于动态建模部分–不存在没有参与者的用例用例不是全部的系统需求–只是功能性的需求。用例之间的关系: (1)泛化关系:泛化(Generalization)代表一般与特殊的关系,与继承关系类似。在泛化关系中,子用例继承了父用例的行为和含义,也可以增加新的行为和含义,或覆盖父用例中的行为和含义。当发现系统中有两个或多个用例在行为、结构和目的方面存在共性时,就可以使用泛化关系。这时,可以用一个新的(通常也是抽象的)用例(父用例)来描述这些共有部分。 (2)包含关系:一个用例(基本用例)的行为包含(Include)了另一个用例(包含用例) 的行为。包含关系是依赖关系的版型–也就是说包含关系是比较特殊的依赖关系–它们比一般的依赖关系多了一些语义。当发现系统中有两个或多个用例有某些相同的动作–就可以这些相同的动作提取出来–单独构成一个用例(包含用例)–基本用例仅仅依赖包含用例执行的结果–而不依赖包含用例执行的内部结构。 (3)扩展关系:一个用例(基本用例)的行为包含了另一个用例(扩展用例)的行为。扩展(Extend)关系也是依赖关系的版型。相对于包含关系,扩展用例(Extension Use Case)有更多的规则限制,即基本用例必须申明若干“扩展点” (Extension Point),而扩展用例只能在这些扩展点上增加新的行为和含义。 在基本用例的每一次执行时,包含用例都一定会执行,而扩展用例只是偶尔被执行。用例描述: 没有描述的用例就像一本书的目录–人们只知道该该目录标题–但并不知道该目录的具体内容是什么;系统所要执行的一系列动作序列(事件流)是用例描述(Use Case Specification)主要内容。![]() ![]() ![]() 要求掌握内容 类的属性 [可见性] 属性名 [:类型] [’['多重性 [次序] ‘]’] [=初始值] [{特性}] 可见性:Java也叫访问控制 属性名:personNumber 类型:基本数据类型或用户自定义类型(类) 多重性:如1…*表示该属性值有一个或多个,还可以是有序的(用ordered指明) 约束特性:changeable(可变的); addOnly(只可加); Frozen(冻结的); 作用域:具有类作用域的属性 – Java的静态变量或类变量 具有对象作用域的属性 – 非静态变量或实例变量类的操作 [可见性] 操作名 [(参数列表)] [:返回类型] [{约束特性}] 操作名:setValue 约束特性:文字串(说明操作的一些有关信息) 操作接口:操作名、参数列表和返回类型组成操作接口 操作的实现:操作的具体实现叫方法 类的职责:属性和操作(形式化描述) – 职责(非形式化描述)类之间的关系 (1)关联关系:关联(Association)关系是类与类之间最常用的一种关系 – 是一种结构化关系 – 用于表示一类对象与另一类对象之间有联系 – 如汽车和轮胎、班级和学生等等用Java等实现关联关系时通常将一个类的对象作为另一个类的成员变量 ●双向关联; ●单向关联; ●自关联; ●多重性关联; ●聚合关系; ●组合关系 (2)依赖关系:依赖(Dependency)关系是一种使用关系–大多数情况下–依赖关系体现在某个类的方法使用另一个类的对象作为参数 – 驾驶员开车–在Driver类的drive( )方法中将Car类型的对象car作为一个参数传递 – 以便在drive( )方法中能够调用car的move( )方法–且驾驶员的drive( )方法依赖车的move( )方法–因此类Driver依赖类Car (3)泛化关系:泛化(Generalization)关系也就是继承关系 – 用于描述父类与子类之间的关系–父类又称作基类或超类–子类又称作派生类类版型 实体类:保存需要放进持久存储体(数据库-文件等)的信息–通常实体类在数据库中有 相应的表(实体的属性对应表的字段) – 但不一定一一对应 边界类:位于系统与外界的交界处-它是系统内的对象和系统外的参与者的联系媒介 窗体-对话框-报表-表示通讯协议-直接与外部设备(如打印机和扫描仪)交互 的类-直接与外部系统交互的类等都是边界类的例子 控制类:协调边界类和实体类之间的交互–如果用例逻辑比较简单可以不用控制类而 直接利用边界类来操作实体类实现业务逻辑 引入边界类-控制类-实体类的概念-有助于分析人员和设计人员确定系统中的类;一般按下面的BEC模式进行分析和设计。 BEC模式:将对象分为三类–边界对象-控制对象-实体对象 ●参与者只能与边界对象互动 ●每个用例可以对应生成一个控制类 ●实体对象一般不能发送消息给边界对象和控制对象(返回消息除外)类图 类及其关系–构成类图–描述的是类和类之间的静态关系;在软件开发的不同阶段使用的类图具有不同的抽象层次。 领域模型–从面向对象的视角看待现实世界–主要工作是找出相关类–然后明确它们的关系–必要时加入一些多重性描述和业务规则–不涉及具体语言 分析模型–从领域模型将得到实体类–对软件系统进行分析–可以得到边界类;描述的是软件的接口–不是软件的实现–最利于开发者使用和交流的类图 设计模型–加入了抽象类–接口等设计元素–加入了设计模式等–描述了类的实现细节-可以直接映射到可执行代码–因此–涉及具体语言和设计模式等对象图 表示一组对象及它们之间的联系–是系统的详细状态在某一时刻的快照;常用于表示复杂的类图的一个实例; 对象是类的实例–对象之间的链是类之间的关联的实例–因此–对象图实质上是具有关联关系的类图的实例。 复习题 4-1. 下面那个类图的表示是错误的( )![]() ![]() ![]() ![]() 要求掌握内容 1.几个重要的概念 210 运算结果是 1024. 要求掌握内容 几个重要的概念![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() https://blog.csdn.net/bueke/article/details/105522391 |
CopyRight 2018-2019 实验室设备网 版权所有 |